Systems for accessing data stores from object oriented languages have been used for many years. A frequent approach to accomplish access of data stores involves writing and embedding custom access code within an object application needing the access. This approach is generally limited to having the custom code access only a single relational table within a relational database or similar construct within any other data store (hereinafter collectively “data store”). Under the circumstances where a developer has control over the design and creation of a data store from its inception, it is possible to design and store meaningful information in a single table. Such design opportunities are usually rare, however.
Generally, the methods for producing persistence for a data object, complex data object or a data store conflict with the goals of producing pure object application models where the object models do not include persistence objects or persistence byte code. Particular difficulties exist in a distributed environment since an object application model may exist in one or more of a computer's memory, an application data store and an application information storage repository that may be independent of the data store organization or object definitions. Advancements in the art have been made with respect to tools for conveniently mapping objects to systems of tables and maps in order to expedite accessing, changing and updating data stores. See, for example, U.S. Pat. No. 5,857,197 (and its associated programming interfaces (“APIs”)) describes tools for translating object data to relational data, relational data to object data, and object data to object data to expedite the use of data stores. The BMP and the CMP Installer portions of CocoAdmin tool in the CocoBase™ Enterprise for O/R Binary Software (Thought, Inc. 657 Mission Street Suite 202, San Francisco, Calif. 94105 http://www.thoughtinc.com,) provide means for providing persistence in the EJB environment.
Persistence problems arise with the creation, access, changing or deleting of an object application model that utilizes such data stores. The object application model may be distributed over multiple physical computer machine locations or even distributed over multiple Internet website locations that may be independent of the data stores. The object application model may utilize a different set of data objects or different set of definitions for relationships between data objects than that of one or more of its data sources. In most situations, the respective structures of the data sources and of the object applications model simply do not conveniently allow for mapping, accessing or changing of an overall schema of application data objects as well as any associated definitions of relationships between two or more data objects or elements within a data object.
Importantly, relationships may exist between a data object and one or more of the other data objects found in the object application model or in a data object of the data source. A relationship between one data object and another data object or with a data source may be member selected from the group of three relationship types consisting of 1 to 1(1-1), 1 to many (1-M) or many to many (M-M). Complex combinations of these relationships may exist as a data object relationships definition for a given data object. These relationships are described or illustrated in further detail later in this document.
Objects may logically span multiple relational tables or multiple object databases, and may even be distributed over a logical (or hypothetical) computer system involving multiple physically independent computer systems or even multiple website locations. Creating, accessing, maintaining or updating an object application model can require working with multiple translation modules and require tedious and repetitive updating of multiple individual computer systems or multiple data sources in order to do useful work and keep the object application model synchronized. Such approaches are both costly and unwieldy in terms of computing and development resources, particularly with respect to Internet based electronic commerce (eCommerce) object application models.
Data objects of an object application model are often a feature of eCommerce object programming applications, where information is obtained from a data source and the data is defined as a data object (e.g., as a Java class) for use with another computer application. In practice, a data object or model of data objects may exist only in the random access memory of a computer memory system, or may be saved to either a data source or to some other type of retrievable information repository. A programmer or administrator of an object data application cannot easily access or track the overall model or diagram of data objects for an object application model or some of its specific elements. Unfortunately, tools for accessing and persisting data objects and associated data object relationships of a complex data object graph model have not been well implemented in the field of object language programming.
A computer application can execute one or more of the following non-limiting actions with respect to one or more of the members selected from the group consisting of data, a data object, and a data object definition: access data, change data, create data, create a new relationship between one or more data objects by creating or changing at least one data object relationship definition, change or delete a relationship between one or more data objects by changing or deleting at least one data object relationship definition, access a data object relationship definition and use its parameters to access a data source or a data object, and access one or more data object relationship definitions or data objects to create a new data object or data object relationship. Any changes executed by a computer application with respect to one or more of the members selected from the group consisting of data, data object or data object definition may need to be properly persisted (permanently stored) to preserve any changes to one or more of the members selected from the group consisting of data, a data object and a data object definition.
A data object and an associated data object relationship definition may be represented by a complex data object graph (“CDOG”). A CDOG, for the purposes of this document, may be thought of as a computer program data object graph that represents a data object having at least one relationship with at least one other data object or with itself via a circular link. When the data object of a CDOG is implemented in the Java computer program language, the CDOG may be further defined as being a Java Data Object Graph (“JDOG”).
There are needs for software, methods and systems that can easily detect and persist any changes to at least one member selected from the group consisting of a data object, any data associated with the related object, or any associated CDOG definition (i.e., an changes to the data object, data or to a relationship of the data object with another data object). For example, there is a need to be able access a pure object model definition from a repository based O/R mapping tool or from a modeling tool repository and provide persistence for the object model without inserting any byte code or additional objects into the object model.
Accordingly, there is a strong need in the art for a computer applications programmer tool designed to assist a programmer or administrator in the actions of providing persistence for data objects or data object graphs when deleting, inactivating or updating a CDOG, wherein the computer applications programmer tool can be configured to automatically reconcile all or a portion of a CDOG and copies thereof on a distributed environment when data objects or relationships are inserted, deleted, inactivated or updated for a CDOG. A particularly strong need exists for such a tool having the further ability to be configured to persist, propagate and reflect system wide (in a local or distributed computer system) any such changes to a CDOG instance to all instances of the CDOG and to all instances of associated data, data objects and data object relationships.
Definitions
The following non-exhaustive list of definitions is used herein to define terms that may otherwise be confusing or can sometimes have multiple meanings. Each occurrence of a defined term in the above text, in the text that follows, or in the claims of this document, is to be given the meaning ascribed to it in the list of definitions below.
“Instance” as referred to in this document in the context of computer software applications is a single occurrence of a software logical element in the memory of a computer system, such as a “class”, an “object”, a “data object”, and the like. This is analogous to the occurrence of a logical memory unit representing a row of data in common practice.
“Class” as referred to in this document in the context of computer software applications is a logic unit in a computer application or a computer software program where the application or program is based upon an objected oriented programming language (e.g., Java). In practice, a class is a logical unit used as a logical template in an object oriented language from which to allocate new instances of objects.
“Object” as used in the context of this document is a general term referring to a logic unit in a computer application or a computer software program where the application or program is based upon an objected oriented programming language (e.g., Java). The term “object” may ordinarily be used interchangeably with the term “class” as a template or as an instance depending on the context.
“Data object” as referred to in the context of this document represents the concept of the occurrence of an object that holds data within a specific computer application domain and is likely to have its contents stored in a persistent data source of a computer system (e.g., a database server, a binary file, a text file, or even in a combination of two or more of such a persistent data sources of a computer system). A data object may exist as an independent data object without any relationship to any other data object or it may have one or more relationships with itself or with one or more other data objects.
“Complex data object” (or “CDO”) as used in the context of this document refers to the occurrence of a data object that has at least one or more relationships with itself, or at least one or more relationships with one or more other data object(s). In a given instance of a CDO at least one relationship is populated as a link, as defined below. A CDO may have a multiplicity of different relationships with itself or with one or more additional CDOs.
“Relationship” or “data relationship” as used in the context of a CDO refers to the type of logical combination that occurs between a data object with itself, or refers to the type of logical combination that occurs between a data object and at least one another data object. Among other references or descriptions, such a relationship is always referred to or partially described by a “relationship type”. This term is used in an object oriented language context to reference or describe any expectations, actions and limitations possible between two or more data objects.
“Relationship type” in the context of this document is a label that specifies the possible multiple combinations that can occur between a CDO and itself or with at least one other CDO. The possible relationship type labels are 1-1 (one to one), 1-M (one to many) and M-M (many to many). A given CDO may be simultaneously related to more than one other CDO through several different types of relationship. This is also sometimes referred to as the multiplicity of the relationship.
“Link” as used in this document with respect to a CDO identifies a particular occurrence of a relationship between a CDO and itself, between a CDO and another CDO. The occurrence of at least one populated link results in an instance of the CDO. This may be considered a synonym for a “relationship” between two objects.
“Circular link” as used in this document with respect to a CDO identifies a particular occurrence of a relationship between a CDO and itself that may be direct or indirect (e.g., linked to itself through another CDO).
“Relationship definition” or “relationship description” in the context of this document and computer software applications refers to information, or an abstraction of information, regarding a “relationship”, “data relationship” “relationship type” or a “link” that can be stored, accessed, transferred, communicated, displayed or edited.
“Complex data object graph” or “CDOG” is a term employed herein as an abstraction to logically represent a set of complex data objects and a set of their corresponding relationships.
“Java data object graph” or “JDOG” is a term employed herein as an abstraction to logically represent a set of complex data objects and a set of their corresponding relationships that are part of a Java programming application.
“Application model” or simply “model” are essentially interchangeable terms employed herein as abstractions to logically convey a collective description or other representation for a set of complex data objects and a corresponding description or other representation of their relationships. In one respect, these terms are used logically herein provide a general way of efficiently communicating when referring to set of metadata (i.e., data about data) that describes possible data entities (e.g., objects, database tables, maps, etc,) data relationship types, and data constraints involved in a computer system or application, or in a specific instance of an application. It is important to understand the context in which the terms “application model” and “model” are used in this document. Ordinarily computer engineers refer to the “model” as an abstraction rather than a specific possibility or instance of the model as applied. However, in this document for the ease of communication abstractions of the model, possible implementations of the model and instances of the model are all referred to generally as “application model” or “model”. From the context of its use the term will be clear. The model is the abstract relationship between classes, wherein the CEDO is an instance (or set of instances) that express(es) the model.
“Navigation”, “navigating” or “navigated” in the context of the present document refers to an action implementing at least one object to interact with a set of related objects for a certain purpose, such as creation, access, insertion, modification and deletion of an object, or of one of its relationships. It is the physical act of traversing the relationships, which might be referred to as “walking up or down the graph” in common lingo.
“Navigation model” as used herein is a special type of application model that is applied specifically to a description (or other representation) of how objects can relate to each other and what might be the expected behavior when a CDOG is navigated for a certain purpose.
“Object schema” is a term employed herein as an abstraction referring to the set of data object classes that describe the possible data objects that can be created, modified or maintained in an application, or describing an instance of a set of data object classes in an application.
“Distributed Transparent Persistence” is a term employed herein as an abstraction referring to the concept of providing persistence for a member selected from the group consisting of a data object, a data object graph, associated data and data object relationships in a distributed environment without the need for the insertion of byte code or data objects in an object model or schema.
“CocoBase Proxy Classes” is a term employed herein used in referring to wrapper classes that provide CocoBase runtime compatibility for objects that aren't inherently database aware. A computer system can persist the attributes and data for any data object that is wrapped with a CocoProxy wrapper class by simply using CocoBase facilities. For example, source code for the (attribute based) CocoProxy and (get/set method based) CocoProxyM classes are available under the thought\cocodemo3tier31\demos\pguide directory, when the CocoBase software tools suite is installed on a computer system. This optional design provides an extensible mechanism for instances of data extraction and propagation.
“CocoBase Navigation API” is a term employed herein to refer to an example of an API that provides database relationship mapping and object graph management capability for persistent objects. Database relationships are mapped to object links using CocoBase Navigator link definitions. Persistence control is provided at each class level in the object graph. Each of the Select, Insert, Update and Delete operations are individually configurable.
“CocoBase Transaction API” is a term employed herein to refer to an example of an API that provides object oriented transaction support. Transaction objects are used to persist data object attributes and maintain synchronization between database and in memory attribute values. The Transaction API has many built in optimizations, and applications utilizing CocoBase transactions generally benefit from reduced database and network overhead. This facility allows the developer to group together object changes into a single unit of work whose implementation or storage will succeed or fail all at once.
“CocoBase Factories” is a term employed herein to refer to examples of software modules and softwares libraries that are used to provide automated, custom object instantiation behavior. Factory behavior is completely customizable. For example, a factory may be used to bind newly instantiated objects to a transaction object, to load a graph of related objects using the CocoBase Navigator, or to implement polymorphism in a database result set. For example, a ProxyFactory class is part of the current CocoBase software tools suite distribution in the thought\cocodemo3tier31\demos\pguide directory, and this factory returns result set objects wrapped in a CocoProxy wrapper, when a CocoProxy wrapped key object is passed into the CocoBase runtime software module as part of a query that needs processing by the CocoBase runtime module.
“CocoBase Repository” is a term employed herein as an abstraction referring to a datasource to dataobject mapping repository and associated software modules that is installed into a datasource (or may optionally be a single stand alone file or set of files that circumscribe a set of datasource to dataobject mapping definitions and associated software modules, or may be an alternate data source). A repository can optionally be in a format such as XML, XMI and the like. See, U.S. Pat. No. 5,857,197, the CocoBaseEnterprise O/R Tools Suite, and the co-pending patent appliction entitled “Dynamic Object-Driven Database Manipulation and Mapping System” for more detailed descriptions of mapping repositories, and the like.
“CocoBase Transparent Persistence for Objects and Object Models”. All models using a relational database for map storage require the CocoBase repository to be installed into the database, or in a stand-alone source accessable to CocoBase. The installation of a mapping repository can occur automatically, if required, when using CocoAdmin to log into the database. Pre-existing database tables can be used, provided that the CocoBase repository is first installed into the database, or accessible to CocoBase from an alternate location. Several example of applications that implement CocoBase transparent persistence are included in the CocoBase software tools suite distribution (see the distribution documentation for the location of folders or directories containing such examples).